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Status of this Memo 
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improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
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1. Abstract 
This document records the errors found in the Megaco/H.248 protocol 
document [2], along with the changes proposed in the text of that 
document to resolve them. 

2. Conventions used in this document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC-2119 [1]. 

3. Errata 
All section numbers are those of the relevant text of [2]. 
Section: 2 "References" 


Editorial: Add missing references to 1.363.5 (AAL5) and RFC 1661 
(PPP). 


Editorial: delete unused reference to Q.724. 


Editorial: Leave Recommendations referred to in Annex C undated, 
implying latest issue. 


Editorial: add reference to RFC 2805, the Megaco requirements 
document. 
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Section: 4 "Abbreviations" 


Editorial: delete unused abbreviation BRI. 
Editorial: add explanations for GSM and IVR. 


Section: 6.2.2 "TerminationIDs" 


Issue: Not clear what wildcard union responses look like. 


Resolution: Add the following text: 

"ie. Given termination Ta with properties pl=a, p2=b, and 
termination Tb with properties p2=c, p3=d a UNION 
response would be T* pl=a, p2=b,c, p3=d." 


Section: 6.2.4 "Termination Properties and descriptors" 

Issue: Says that property values set in Null context are remembered 
and reinstated when termination returns to Null. Contradicts latest 
text in 7.2.3. 


Resolution: Rewrite the first paragraph from the third sentence 
onward, to read: "Most properties have default values, which are 
explicitly defined in this standard or in a package (see Section 12) 
or set by provisioning. If not provisioned otherwise, all 
descriptors except for TerminationState and LocalControl default to 
empty/"no value" when a termination is first created or is returned 
to the null context. The default contents of the two exceptions are 
described in sections 7.1.5 and 7.1.7." 


Issue: DigitMap entry in table makes explicit reference to DIMF 
tones, but is also intended to apply to other in-band signalling 
systems. 


Resolution: Change existing text to new one as follows: "Defines 
patterns against which sequences of a specified set of events are to 
be matched so they can be reported as a group rather than singly." 


Section: 6.2.5 "Root Termination" 


Issue: Root can have statistics as well as properties and events. 
Resolution: add "statistics" to the fourth sentence of the first 


paragraph, listing what is valid for Root. Add "statistics" to what 
AuditValue can return for Root. 
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Section: 7.1 "Descriptors" 


Issue: it is unclear how to express empty descriptors in responses to 
the MGC. 


Proposed resolution: In section 7.1, add the following text after the 
sentence: "Descriptors may be returned as output from a command.": 
"In any such return of descriptor contents, an empty descriptor is 
represented by its name unaccompanied by any list." 


In the ASN.1, add the following choice to the AuditReturnParameter 
production: 


"emptyDescriptors AuditDescriptor," 


In the ABNF, add the choice auditItem to the production 
auditReturnParameter. 


Section: 7.1.1 "Specifying Parameters" 
Issue: Third paragraph (discussing unspecified parameters): not clear 
which parameters are mandatory. 


Resolution: Replace the first two sentences (each beginning with the 
word "unspecified") with the following text: "If a required 
descriptor other than the Audit descriptor is unspecified (i.e. 
entirely absent) from a command, the previous values set in that 
descriptor for that termination, if any, are retained. A missing 
Audit descriptor is equivalent to an empty Audit descriptor. The 
behaviour of the MG with respect to unspecified parameters within a 
descriptor varies with the descriptor concerned, as indicated in 
succeeding sections." 


Section: 7.1.6 "Stream Descriptor", ABNF (Annex B.2) 


Issue: Text indicates use of "true" and "false" values while ABNF 
uses "on" and "off" 


Resolution: Add comment in B.2 that "true" in text corresponds to 
"on" in ABNF, and "false" corresponds to "off". 
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Section: 7.1.8 "Local and Remote Descriptors" 


Issue: case where reserveGroup or reserveValue is true, last bulleted 
item beginning: "If the Mode property of the LocalControl descriptor 
is RecvOnly or SendRecv,...", could also have DSP involvement in the 
case of loopback mode. 


Resolution: Add "loopback". 


Section: 7.1.9 "Events Descriptor" 


Issue: EventDM is part of syntax but not mentioned in section. 


Resolution: Add text: "If a digit map completion event is present or 
implied in the EventsDescriptor, EventDM is used to carry either the 
name or the value of the associated digit map. See section 7.1.14." 


Issue: Not clear whether events trigger side effects (e.g. signal 
termination) at time of detection, at time of processing (whether or 
not in active Events Descriptor) or at time of notification. Also, 
the third paragraph of the section fails to mention these side 
effects and limits MG action to notification. 


Resolution: Modify the third paragraph of the section, so that it 
reads: "When an event (either newly detected or buffered) is 
processed against the contents of an active Events descriptor and 
found to be present in that descriptor ("recognized"), the default 
action of the MG is to send a Notify command to the MG. Notification 
may be deferred if the event is absorbed into the current dial string 
of an active digit map (see section 7.1.14). Any other action is for 
further study. Moreover, event recognition may cause currently 
active signals to stop, or may cause the current Events and/or 
Signals descriptor to be replaced, as described at the end of this 
section." 


Replace "detection" with "recognition" in the fourth paragraph from 
the end, so that it reads: "Normally, recognition of an event shall 
cause any active signals to stop. When KeepActive is specified in 
the event, the MG shall not interrupt any signals active on the 
Termination on which the event is detected." 


In the third-last paragraph, replace all three instances of 
"detected" with "recognized". 


Leave the word "detected" as is in the final paragraph. 
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Issue: Case 1, step 2(a) is incorrectly formulated. Existing logic 
may result in an infinite loop. Also, the step excludes side effect 
actions such as signal termination. 


Resolution: Modify step 2(a) to read: "If the event in the queue is 
in the events listed in the new EventsDescriptor, the MG acts on the 
event and removes it from the EventBuffer. The time stamp of the 
Notify shall be the time the event was actually detected. The MG 
then waits for a new EventsDescriptor. While waiting for a new 
EventsDescriptor, any events detected which appear in the current 
EventsBufferDescriptor will be placed in the EventBuffer. When a new 
EventDescriptor is received, event processing repeats from step 1." 


Section: 7.1.11 "Signals Descriptor" 


Issue: There is a need for the MGC to be aware of signalling 


failures. It is not possible to use the signal completion event to 
monitor for signalling failures only, without also having to process 
successes. 


Proposed Resolution: In section 7.1.11, replace the current text on 
completion notification, beginning: "Finally, the optional parameter 
"notifyCompletion" ..." and continuing to the end of the paragraph 
with the following text: 


"Finally, the optional parameter "notifyCompletion" allows a MGC to 
indicate the circumstances under which it wishes to be notified when 
the signal finishes playout. The possible cases are that the signal 
timed out, that it was interrupted by an event, that it was halted 
when a Signals descriptor was replaced, or that it stopped or never 
started for other reasons. If "notifyCompletion" is absent, 
notification is generated in the "other reasons" case only. For 
reporting to occur the signal completion event (see section E.1.2) 
must be enabled in the currently active Events descriptor." 


In Annex A.2, make notifyCompletion a BIT STRING with the four cases. 
In B.2, make it a parameter consisting of a name and a list of values 
representing the possible completion methods. 


Section: 7.1.13 "ServiceChange Descriptor" 


Issue: Missing "extension" component in the API. 


Resolution: Add missing component. 
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Section: 7.1.14 "DigitMap Descriptor" 


Editorial: add the following subsections. 


7.1.14.1 DigitMap definition, creation, modification and termination 
(before first paragraph) 


7.1.14.2 DigitMap Timers (after the first bullet list) 


7.1.14.3 DigitMap syntax (before the long paragraph starting "The 
formal syntax of the digit map [...]") 


7.1.14.4 DigitMap completion event (before the paragraph starting "A 
digit map is active while the events descriptor [...]") 


7.1.14.5 DigitMap procedures (before the sentence "Pending 
completion, successive events shall be processed [...]", preceding 
the numbered list) 


7.1.14.6 DigitMap activation (after the numbered list) 


7.1.14.7 Interaction of DigitMap and event processing (before the 
next paragraph, starting "While the digit map is activated, [...]") 


7.1.14.8 Wildcards (before the the next paragraph, starting "Note 
that if a package contains [...]") 


7.1.14.9 Example (before the example) 


Issue: incorrect statements regarding the interaction of the dot 
symbol with default timing rules. 


Resolution: last sentence of the paragraph beginning "The letter "x" 


is used as a wildcard, ..." should be modified to read: "As a 
consequence of the third timing rule above, inter-event timing while 
matching a terminal dot symbol uses the short timer by default." In 
the next paragraph, the third sentence, which begins: "A timer 
specifier following a dot ...", should be deleted. 


Issue: Step 5 in second numbered list understates conditions for 
digit map completion when single candidate remains. 


Resolution: Add the words "and it has been fully matched" to the 
existing sentence. Also remove the parenthetical remark: ". 
(because the candidate set still contains more than one alternative 
event sequence)" from step 6. 
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Issue: Not clear when unmatched events are recognized and trigger 
side effects (e.g. signal termination). 


Resolution: Modify the final sentence of the paragraph following 
procedural step 6 to read as follows: "Normal event behaviour (e.g. 
stopping of signals unless the digit completion event has the 
KeepActive flag enabled) continues to apply for each such event 
detected, except that 


the events in the package containing the specified digit map 
completion event other than the completion event itself are not 
individually notified, and 

an event which triggers a "partial match" completion is not 
recognized and therefore has no side effects until reprocessed 
following the recognition of the digit map completion event." 


Issue: the last paragraph before the example is misleading if the 
package containing the digit map completion event is different from 
the package containing the actual digits. 


Resolution: qualify the second sentence of the paragraph as follows: 
"Regardless of whether a digit map is activated, if the package also 
contains the digit events themselves, this form of event 
specification ae 


Section: 7.1.18 "Topology Descriptor" 
Issue: Third bullet attached to third para: says loopback achieved by 
manipulating TerminationMode, which no longer has that name. 


Resolution: Delete the clause "; loopbacks are created by setting the 
TerminationMode" 


Issue: The order in which descriptors are processed within a command 
matters, but is not clear. Moreover, it is fixed in the ASN.1 but 
variable in the ABNF. 


Resolution: Add text stating that descriptors are processed in the 
order in which they are provided. Change ASN.1 in Annex A.2 to allow 
the MGC to specify ordering: 
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AmmRequest ::= SEQUENCE 

{ 
terminationID TerminationIDList, 
descriptors SEQUENCE OF AmmDescriptor, 


-—- At most one descriptor of each type (see AmmDescriptor) 
-- allowed in the sequence 


} 


AmmDescriptor ::= CHOICE 

{ 
mediaDescriptor MediaDescriptor, 
modemDescriptor ModemDescriptor, 
muxDescriptor MuxDescriptor, 
eventsDescriptor EventsDescriptor, 
eventBufferDescriptor EventBufferDescriptor, 
signalsDescriptor SignalsDescriptor, 
digitMapDescriptor DigitMapDescriptor, 
auditDescriptor AuditDescriptor, 


} 


Section: 7.2.3 "Subtract" 
Issue: cannot use the CHOOSE wildcard for terminationId of a Subtract 
command. 


Resolution: add this qualification to the second sentence, which 
indicates that terminationId may be wildcarded. 


Section: 7.2.4 "Move" 
Issue: cannot use the CHOOSE wildcard for terminationId of a Move 
command. 


Resolution: add this qualification to the second sentence, which 
indicates that terminationId may be wildcarded. 


Section: 7.2.5 "AuditValue" 
Issue: Not clear whether AuditValue of ObservedEventsDescriptor 
reports events captured in current dial string of active digit map. 


Resolution: Add text to indicate that if a digit map is active and 

ObservedEventsDescriptor is specified the response to an AuditValue 
includes a digit map completion event which shows the current dial 

string but does not show a termination method. 
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Issue: Fails to indicate what AuditValue for EventBufferDescriptor 
returns 


Resolution: Add the following text: "EventBuffer returns the set of 
events and associated parameter values currently enabled in the 
EventBufferDescriptor." 


Issue: not clear whether wildcarded context includes the null 
context. 


Resolution: add statement that ALL as a contextID does not include 
the null context. 


Issue: the text of 7.2.5 allows retrieval of multiple digit maps with 
one AuditValue command if the terminationId is ALL. Moreover, 
earlier text in the Annex anticipates that multiple instances of a 
descriptor may be returned. The comment in front of production 
auditReturnParameter in Annex B.2 contradicts this text. Note that 
Annex A has no restriction on the number of instances of any 
descriptor in either a command or a response. 


Proposed Resolution: delete the"at-most-once" comment preceding ABNF 
production auditReturnParameter. 


Issue: Does not indicate how an audit of digit maps returns unnamed 
digit maps. 


Resolution: Change syntax of DigitMapDescriptor to allow return of 
unnamed digit maps as follows: 


digitMapDescriptor = DigitMapToken EQUAL 

( (LBRKT digitMapValue RBRKT) 
/ (digitMapname [ LBRKT digitMapValue RBRKT ]) 
) 


and 
DigitMapDescriptor = SEQUENCE { 
digitMapName DigitMapName OPTIONAL, 


digitMapValue DigitMapValue OPTIONAL } 


Issue: the text in section 7.2.5 mentions that using an empty Audit 
descriptor with a wildcarded terminationId is a way to get a list of 
the terminations in the context. Annex A provides the possibility 
that the auditReply may be a contextAuditResult of type 
terminationIdList, and Annex B allows for an auditReply containing a 
contextTerminationAudit which in turn presents a terminationIdList. 
The connection between the text in 7.2.5 and these special forms of 
audit result is not clear. Moreover, a note at the beginning of 
Annex A section A.2 limits terminationIdList to one terminationId. 
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Proposed Resolution: add the following text in section 7.2.5 after 
the sentence "This may be useful to get a list of TerminationIDs when 
used with wildcard.": "Annexes A and B provide a special syntax for 
presenting such a list in condensed form, such that the AuditValue 
command tag does not have to be repeated for each terminationId." 
Also, in the Note at the beginning of section A.2 of Annex A, provide 
an exception on the length of type TerminationIdList when used in 
contextAuditResult. 


Section: 7.2.6 "AuditCapabilities" 
Issue: Fails to indicate what AuditCapabilities for 
EventBufferDescriptor returns 


Resolution: Add the following text: "EventBuffer returns the same 
information as Events." 


Issue: Inconsistency regarding permissibility of DigitMap or Packages 
as capability audit items. 


Resolution: Add comment to B.2 "auditItem" production indicating that 
DigitMap and Packages are not allowed in the AuditCapabilities 
command. 


Section: 7.2.8 "ServiceChange" 


Issue: In point 1) describing the Graceful ServiceChange method, the 
scope of the recommendation against new connections is unclear. 


Resolution: at the end of the first sentence, add the phrase "on the 
termination(s) affected by the ServiceChange command". 


Issue: the explanatory string associated with ServiceChangeReason is 
optional in the syntax, but not in the text. 


Resolution: add "optional" before "explanatory string" in the 
explanation of the ServiceChangeReason" parameter. 


Issue: Paragraph beginning "A ServiceChange Command specifying the 
Root..." immediately following the description of ServiceChange 
Descriptor parameters erroneously states that the response to the 
ServiceChange command terminates the registration process. This is 
so only if the response does not specify an alternate MGC. 


Resolution: Add text to the offending sentence, so that it reads: 
"Acknowledgement of the ServiceChange Command completes the 
registration process, except when the MGC has returned an alternative 
ServiceChangeMgcId as described in the next paragraph." 
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Section: 7.3 "Command Error Codes" 


Issue: Text for error code 403 should be consistent with that for 404 
and 405. 


Resolution: Change text to "Syntax error in TransactionRequest" 


Issue: There should be no error responses to TransactionReply or 
TransactionPending, lest they create response loops. 


Resolution: Delete codes 404, 405, 461-467 


Section: 8 "Transactions", A.2 


Issue: state is unclear if a command fails. 


Resolution: add the following text: "If a command fails, the MG 
shall as far as possible restore the state which prevailed prior to 
the attempted execution of the command before continuing with 
transaction processing." 


Section: 8.1.1 "Transaction Identifiers" 


Issue: need a transaction identifier to use when reporting a syntax 
error such that the identifier is unavailable. 


Resolution: add text reserving transionId = 0 for this purpose. 


Section: 8.1.2 "Context Identifiers" 


Issue: ALL as a context identifier does not include the null context. 


Resolution: add text to indicate that exclusion in the final sentence 
of the section. 


Section: 8.2.2 "TransactionReply" 


Issue: Final para has wrong text for error code 442. 
Resolution: Change to "Syntax Error in Command" 


Section: 10.2 "Interim AH Scheme", B.2 

Issue: The interim AH header can actually be as short as 24 hex 
digits (per RFCs 2403, 2404 which are indirectly referenced). It is 
also unclear whether it is the source or destination UDP port which 
is prepended in the calculation. 
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Resolution: Change 10.2 second para, second-last sentence to specify 
the destination port, in consistency with IPSEC. In Annex B.2, 
change lower count for production AuthData to 24 from 32. 


Section: 11.2 "Cold Start" 
Issue: First paragraph last sentence inadvertently modified -- 
duplicates material in 11.3. 


Resolution: Restore original sentence: "If the MG is unable to 
establish a control relationship with any MGC, it shall wait a random 
amount of time as described in Section 9.2 and then start contacting 
its primary, and if necessary, its secondary MGCs again." 


Section: 11.4 "Failure Of an MG" 
Issue: Second para: wrong MG is specified as the one to be used after 
failover. 


Resolution: Change fourth sentence to refer to "secondary MG" rather 
than "primary MG". 


Section: 12.1.2 "Properties" 
Issue: As indicated in 6.2.4, Properties occur in other descriptors 
besides LocalControl and TerminationState. 


Resolution: after the sentence mentioning TerminationState, add 
another sentence: "Although these are the most common cases, it is 
also possible for a property to be defined for other descriptors." 


Section: 12.1.4 "Signals" 


Issue: Note says that default duration should be specified for BR 
signals. This also applies to TO signals. 


Resolution: Add TO signals to note. 


Section: 12.2 "Guidelines to defining Properties, Statistics and 
Parameters to Events and Signals", B.2 

Issue: Text indicates that statistics can have the sub-list data 
type, but ABNF does not support that. 


Resolution: qualify the sublist type by adding the note: "(not 
supported for statistics)". 
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Section: Annex A.1, ASN.1 Syntax 

Issue: the ASN.1 uses the values 0x0, OxFFFFFFFE, and OxFFFFFFFF for 
the NULL context, a wildcard CHOOSE of context, and a wildcard ALL of 
context respectively. Because of the possibility of a switch between 
binary and text encoding for messages relating to the same context, 
these values should be reserved in the text encoded syntax. 


Resolution: Add a comment preceding the ContextID production in Annex 
B.2 indicating that these values are reserved. 


Section: Annex A.2, ASN.1 Syntax 

Issue: sloppy ASN.1 -- in production EventBufferControl the values 
"off" and "lockstep" should not be capitalized, and IA5STRING in 
production NonStandardIdentifier should be IA5String. Both 
TransactionID and TransactionId are used. A number of productions 
need ellipses to express extensibility. 


Resolution: fix them. 


Issue: syntax for PropertyParm does not support sub-lists (i.e. 
parameters supporting multiple values simultaneously) 


Resolution: add a third choice to extrainfo in PropertyParm as 


follows: 
extraInfo CHOICE 
{ 
relation Relation, 
range BOOLEAN, 
sublist BOOLEAN 
} OPTIONAL 


and add an appropriate note to the preceding comments. 


Issue: LocalControlDescriptor still contains reserve rather than 
reserveValue and reserveGroup. 


Resolution: Replace reserve with separate reserveValue and 
reserveGroup Booleans. 


Issue: EventBufferDescriptor is incorrectly portrayed as a SEQUENCE 
OF ObservedEvent. 


Resolution: replace with the following productions: 
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SEQUENCE OF EventSpec 


EventSpec = SEQUENCE { 
pkgdName PkgdName, 
streamID StreamID OPTIONAL, 
evParList SEQUENCE OF EventParameter } 


Issue: Assigned object identifie 


a matter of convention. 
Resolution: Add object identifie 
content: 

"itu-t recommendation h 248 
version field, which this makes 


Issue: the T.35 country code in 
not have the right structure. 
Resolution: fix it. 


Section: Annex B.2, 


ABNF Syntax 


Issue: Syntax for parmValue and 
ambiguous. Furthermore, sub-lis 
have the same syntax, introducin 


Resolution: Replace production a 
"alternativeValue ( VALUE 


/ LSBRKT VALUE * (COMMA VALUE) 


/ LBRKT VALUE * (COMMA VAL 
/ LSBRKT VALUE COLON VALU 


Issue: EventBufferDescriptor con 
of observedEvent. 


Resolution: replace the producti 
following productions: 


eventBufferDescriptor = EventBuf 
*( COMMA eventSpec ) ] RBRKT 
eventSpec = pkgdName [ LBRKT ev 
* ( COMMA 

eventSpecParameter = ( eventStre 
Issue: Error in syntax for digi 
optional. 

Taylor Standar 


r missing. It is usually present as 


r line in the message header with 


media-gateway-control(0)" Delete the 
redundant. 


the H221NonStandard production does 


VALUE together make parsing of range 
ts and sets of alternative values 
g possible ambiguity 


lternativeValue by the following: 


RSBRKT ; sub-list 
UE) RBRKT ; alternatives 
E RSBRKT ) ; range" 


tent mistakenly shown as a sequence 


on for eventBufferDescriptor with the 


ferToken LBRKT [ eventSpec 


entSpecParameter 
eventSpecParameter 


) RBRKT ] 


am / eventOther 


) 


tMapDescriptor: value meant to be 
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Resolution: Change production: 
digitMapDescriptor = DigitMapToken EQUAL digitMapName 
[ LBRKT digitMapValue RBRKT ] 


Issue: VersionToken not defined. 
Resolution: Add ABNF: VersionToken = ("Version" / "v") 
Issue: DiscardToken not used. 


Resolution: Delete production. 


Issue: alignment of sub-octet fields within the octet is not 
indicated. 


Resolution: add note that fields of sub-octet length are placed in 
the low-order bits of the octet. 


Section: Annex C, ATM-related sections C.4, C.7, C.8, C.10 


Issue: direction of flow is segregated by outgoing (Remote 
descriptor) and incoming (Local descriptor). Since forward and 
backward properties will not both reside in the same descriptor, need 
only the one set of properties applicable to both directions. 


Resolution: replace with a single set of properties. 

Issue: miscellaneous problems of parameter specifications 
inconsistent with the relevant standards, unused parameters, 
distinction between ATM Forum and ITU-T usages, missing references. 
Resolution: fix them. 

Section: Annex C.8 "ATM AAL1" 

Issue: Length of GIT is wrong. 

Resolution: ITU-T procedural problem, to be resolved by SG 16. 
Probable solution is to allow 29 octets, event though the relevant 
form requires only four octets. 

Section: Annex C.9 "Bearer Capabilities" 


Issue: ITC has reference to missing note 2 


Resolution: Delete reference. 
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Issue: Not clear that Q.931 Bearer Capability IE rather than Low 
Layer Compatibility IE is being used. 


Resolution: Specify that values are those valid for Bearer Capability 
IE 


Section: Annex D.1 "Transport over IP/UDP using Application Level 
Framing" 

Issue: Even in the case of handoff or failover, the originating MGC 
needs confirmation that its command was received. 


Resolution: In the last sentence of the first paragraph, delete the 


excepting clause, so that the sentence reads: "Responses must be sent 
to the address and port from which the corresponding commands were 
sent." 


Section: Annex D.1.1 "Providing At-Most-Once Functionality" 
Issue: Second para last sentence provides a procedural reference to 
8.2.3. Should refer to UDP-specific procedures. 


Resolution: Add reference to D.1.4. 


Section: Annex D.1.3 "Repeating Requests, Responses and 
Acknowledgements" 


Issue: Make exponential backoff in the face of congestion mandatory. 


Resolution: To the paragraph just before the note, which begins "The 
specification purposely avoids specifying any value for the 
retransmission timers...", add the following sentence: 


"Implementations SHALL ensure that the algorithm used to calculate 
retransmission timing performs an exponentially increasing backoff of 
the retransmission timeout for each retransmission or repetition 
after the first one." 


In the paragraph in the middle of the note beginning "After any 
retransmission ...", capitalize the word SHOULD to emphasize the 
importance of the steps which follow. 


Issue: Last paragraph is equivocal about what ServiceChangeReason to 


use when recovering from loss of contact; it must always be 
"Disconnected". 
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Resolution: Change the two sentences following the phrase "_ and it 
begins its recovery process" to read as follows: "The MG shall use a 
ServiceChange with ServiceChangeMethod set to disconnected so that 
the new MGC will be aware that the MG lost one or more transactions." 


Section: Annex D.1.4 "Provisional responses" 

Issue: First paragraph, last sentence talks about when to send the 
Transaction Pending response. When UDP/ALF is in use, the originator 
of a transaction may repeat it because it has not received an 
acknowledgement that the transaction was received. An appropriate 
response to a duplicate transaction which is still being processed is 
to return Transaction Pending. 


Resolution: Add the sentence: "They SHOULD send this response if they 
receive a repetition of a transaction that is still being executed." 


Issue: Second para: transaction originator may not have received 
TransactionPending response(s) because they were lost, and may 
therefore not know that responder is expecting immediate 
acknowledgement of the TransactionReply. 


Resolution: add an optional field to TransactionReply allowing the 
responder to indicate if an immediate ACK is required. Add text in 
the section indicating that when the responder has sent a provisional 
response, it shall also set the indicator in the final transaction 
reply to indicate that an immediate acknowledgement is required. 


Section: Annex E "Basic Packages" 


Issue: package numbering does not follow order of presentation. 
Resolution: renumber packages to follow order of numbering. 


Section: Annex E.2.1 "Base Root Package -- Properties" 
Issue: the descriptor in which these properties occur is not 
specified. 


Resolution: in each case, indicate that the property is defined in 
the TerminationState descriptor. 


Section: Annex E.6.2 "DTMF detection Package -- Events" 
Issue: "Long duration event modifier" is shown as "L" in parameter 
DigitString -- should be "z". 


Resolution: Replace with "Z". 
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Section: Annex E.9.2 "Analog Line Supervision Package -- Events" 
Issue: Stated hook state reporting behaviour has race condition where 
same transition could be reported twice. 


Resolution: add an optional EventsDescriptor parameter and an 
optional ObservedEvents parameter to each of the on-hook and off-hook 
events. Delete the second sentence of the existing event description 
(which indicates that the event is always reported if the hook state 
has already been achieved). 


The EventsDescriptor parameter is described as follows: 


Strict Transition 
ParameterID: strict (0x0001) 
Type: enumeration 
Possible values: 
"exact" means that only an actual hook state transition 
to on-hook (off-hook) is to be recognized 


"state" means that the event is to be recognized 

either if the hook state transition is detected or if the 
hook state is already on-hook (off-hook). This is the 
default value if "strict" is unspecified. 


"failWrong" means that if the hook state is already what 
the transition would imply, the command fails and an error 
is reported [error code to be defined in the package]. 


The ObservedEvents parameter is described as follows: 


Initial State 
ParameterID: init (0x0002) 
Type: Boolean 
Possible values: 
true/"ON" means that the event was reported because the 
line was already on-hook (off-hook) when the events 
descriptor containing this event was activated 


false/"OFF" means that the event represents an actual 
state transition to on-hook (off-hook) 


Section: Annex E.10.3 "Basic Continuity Package -- Signals" 


Issue: The rsp signal should continue until the MGC tells the MG to 
stop applying it. 


Resolution: change the type of signal from Timeout to ON/OFF. 
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Section: Annex E.10.5 "Basic Continuity Package -- Procedures" 
Issue: Wording of condition for generating cmp event with "success" 
does not cover case where test also requires successful removal of 
tone. 


Resolution: In the second paragraph of E.10.5 (dealing with test 
initiation), add the words "and any other required conditions are 
satisfied" in the second sentence, as part of the condition upon 
which success is reported. Replace the third paragraph (dealing with 
test response) with the following text: 


"When a MGC wants the MG to respond to a continuity test, it sends a 
command to the MG containing a signals descriptor with the rsp 
signal. Upon reception of a command with the rsp signal, the MG 
either applies a loop-back or (for 2-wire circuits) awaits reception 
of a continuity test tone. In the loop-back case, any incoming 
information shall be reflected back as outgoing information. In the 
2-wire case, any time the appropriate test tone is received, the 
appropriate response tone should be sent. The MGC will determine 
when to remove the rsp signal." 


Section: Appendix A.1.2 "Example -- Collecting Originator Digits and 
Initiating Termination" 


Issue: Step 3 uses a now-obsolete package DSO for echo cancellation. 
Resolution: replace with echo cancellation via package TDM. 


Issue: Step 20 fails to show a returned TerminationStateDescriptor. 
It also contains the erroneous statement that an RTP termination does 
not support events and signals and fails to show a number of other 
descriptors. 


Resolution: 

Delete the sentence containing the erroneous statement. 

Add the following to the Media Descriptor preceding the line "Stream 
= 1 Ti 

"TerminationState { ServiceStates = InService, EventBufferControl = 
OFF }," 


Add lines showing Events, Signals, and DigitMap descriptors 
following the Media descriptor. 


"Events, Signals, DigitMap," 
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4. Security Considerations 


This memo is a supplement to [2], which contains the required 
security section. 
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8. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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